The increasing sophistication of site specific attacks based on man-in-the-middle (MITM) and man-in-the-browser (MITB) techniques has profound implications for our current authentication techniques. Specifically, the strength of the initial login authentication is increasingly becoming less relevant as these attacks manipulate transactions after the legitimate user has provided the initial credentials to login. In reaction to this trend, leading organizations have begun deploying transaction authentication systems, such as EMV-CAP based token authenticators, or have been using out of band authentication (OOBA) techniques to ensure that the user actually intended the transaction being seen at the back end. However, such approaches are inherently not easy to use and consequently, even when deployed, are generally used only for high risk transactions or occasional events like profile changes. For the vast majority of transactions no current authentication solution provides a reasonable point in the “How easy? How secure? How costly?” trade-off.
In prior work (see the related applications identified above), we described innovations that address some of the problems with conventional authentication systems. Specifically, we introduced the notion of using QOOBA techniques to ensure that the user actually intended the transaction being seen at the back end. We also described how these techniques can be used to provide a user with a one time password (OTP) to enable login into a website (i.e. authentication of the user to the website), based on a secret shared between the web site and a QOOBA security server. Thus these techniques can be used to provide the security of one time passwords, but do not require a per user shared secret which all prior one time password systems have required.
We also extended our prior work to address the issue of providing an authentication solution for the vast majority of transactions at a reasonable point in the “How easy? How secure? How costly?” trade-off.
Here, we extend our prior work to consider solutions to the key management problem, which surfaces in various contexts. Three of many potential examples include the following.
Below we will describe various examples of how key management can be beneficially layered on top of a QOOBA architecture. Our first example relates to digital signing. In applications that require digital signing, a user needs to be provisioned a private key and a digital certificate, i.e. a binding of the user's identity and public key as certified by a Certificate Authority. The use of such a private key, which is not known to any 3rd party, including the security server, provides for strong non-repudiation which is necessary for some applications. We follow the industry convention of referring to signatures created with public key cryptography as “digital signatures”. As will be understood by those skilled in the art, signatures based on underlying symmetric cryptography with shared secrets, like that which the QOOBA system as described above already provides, are usually referred to as “electronic signatures”.
Our second example relates to encrypted document delivery. When an encrypted file is sent to a user, for example a PDF of a brokerage statement, the user needs to be provided with the key with which the file was encrypted.
Our third example relates token authenticators. When users are provisioned a token authenticator, either for a one time password generator or a transaction authenticator, the user's token needs to be provided with a shared secret key. Those skilled in the art will recognize that in this context, the shared secret key is often characterized as a “seed”).
In all these examples key management adds directly to the cost of the system, and indirectly effects the security. Keys need to be generated, distributed and maintained in sync. As keys can get lost, corrupted or stolen, key management is usually a significant source of costs, and a point of vulnerability in the system.